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Abstract 

In 2005, Railsback et al. proposed a very simple model {Stupid Model) 
that could be implemented within a couple of hours, and later extended 
to demonstrate the use of common ABM platform functionality. They 
provided implementations of the model in several agent based modelling 
platforms, and compared the platforms for ease of implementation of this 
simple model, and performance. 

In this paper, I implement Railsback et al's Stupid Model in the ^ c tab 
simulation platform, a C++ based modelling platform, demonstrating 
that it is a feasible platform for these sorts of models, and compare the 
performance of the implementation with Repast, Mason and Swarm ver- 
sions. 

1 Introduction 

Newcomers to agent based modelling (ABM) will be confused by the variety 
of different software platforms available to assist in implementing the models. 
Very few comparative studies between the different platforms have been done, 
as it is a time consuming task implementing all but the most trivial of models. 
Furthermore, familiarity with one platform and programming language will lend 
an automatic advantage in any metrics to that platform over other platforms 
that the model implementer is less familiar with. 

In 2005, Railsback et al.[Ji] proposed a very simple model that could be 
implemented within a couple of hours, and later extended to demonstrate the 
use of common ABM platform functionality. They gave it the name "Stupid 
Model" , partly for fun, but also to reiterate the recommendation of Grimm and 
Railsback [5] that modelling projects should start with a "ridiculously simplified 
model". Railsback et al. implemented their model across a range of ABM 
platforms: Objective-C and Java Swarm[T2], Repast[I3] and Mason[9] (both 
pure Java implementations) and Netlogo. This range of platforms reflects the 
authors' collective programming expertise in Objective-C and Java, and with 
Netlogo having low barrier of entry (Logo was a popular language for teaching 
school children in the 1980s). 



Ectab grew out of a simulation platform supporting a particular class of 
model, into a general purpose simulation environment using C++ [IT]. Other 
C++ agent-based modelling environments exist, eg SymBioSysfll j, but none 
are as general purpose as E- C< tab. Other general purpose agent based platforms 
can be used with C++ models. For instance, with Swarm, C++ code can be 
linked to Swarm's objective C library through the shared C language interface, 
and C++ code can be linked to Repast's Java library through the Java Native 
Interface. However, maintaining the interface code quickly becomes prohibitive 
in the face of evolving models, negating much of the benefits in using a simula- 
tion platform in the first place. 

With Ecq_ a h it is possible to have a similar level of functionality as provided 
by Swarm or Repast for models implemented in CH — h, without the interface 
maintenance overhead. Additionally, Ecq_ a b provides features for distributing 
the computation over multiple processors in a way that is easier to program than 
the raw Message Passing Interface (MPI) 16 . With Railsback et al.'s Stupid 
Model specification, the possibility exists for directly comparing an Ecq_ a fo imple- 
mented agent based model with other platforms for both ease of implementation, 
and execution performance. Furthermore, the exercise illuminates those parts 
of Ecq_ a fo requiring improvement. 

1.1 Why C++ 

CH — h |19j is a mature object oriented programming language of more than 20 
years standing. It has been widely adopted in industry, consequently open 
source reference compilers, as well as vendor-tuned optimising compilers exist 
for most contemporary computer architectures. Because of this popularity, and 
the availability of compilers, CH — h has been extensively deployed for scientific 
computing since the mid-1990s. In High Performance Computing (HPC), the 
extreme end of scientific computing, the predominant computing language used 
for applications is Fortran, with code written in Fortran 77, or increasingly 
written using the newer Fortran 90 features. However C/C++ applications also 
make up a substantial fraction of the deployed applications, perhaps as high as 
30%, with C++ standing to C in the same relationship as Fortran 90 does to 
Fortran 77, i.e. typically used as a "better C"0. By contrast, Java[4] has made 
negligible impact in HP(J0. There are several possible reasons for the lack of 
Java adoption in high performance computing. Firstly, most implementations 
compile to a virtual machine, and early Java Virtual Machines (JVMs) had 
performance problems. However, more recent JVMs deploy just in time com- 
pilation, which closes the performance gap between JVM executed code and 
natively compiled code. Secondly, certain language features missing in Java 
(notably operator overloading, and to a lesser extent generic programming) of 

1 These numbers come from a decade of personal experience at managing the resource 
allocation process at a High Performance Computing Centre. These general numbers are 
backed up by anecdotal reports from a number of other people I have corresponded with 

2 Over the ten years of my personal experience, only one project used Java, out of several 
hundred that were mostly C/CH — h or Fortran. 
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C++ (and Fortran 90 for that matter) assist in writing scientific codes that are 
closer to the mathematical specification. However, probably the most signif- 
icant factor is time and innate conservatism of scientific programmers. CH — h 
did not appear significantly in HPC applications until around 15 years after the 
language was first developed. With only a decade under its belt, Java's time as 
an HPC application language might just be beginning [B]. 

However, for agent based simulation, CH — h is not a popular choice, primarily 
due to its lack of reflection. Reflection is the ability to query an object's type 
information at runtime, and in ABM systems like Swarm, reflection is used to 
implement probes, or the ability to observe all parts of a running simulation 
from within a graphical user interface [12]. However, with Classdesc, an effec- 
tive reflection mechanism for C++ is possible [I01IT8] . ^ c tab uses Classdesc to 
implement probing, along with automatic checkpointing, the ability to script 
the model's initialisation and ongoing computation, and for distributing agents 
to exploit any parallel computing capability. 

2 Method 

In line with Railsback et al.'s[T4] methodology, I implemented Stupid Model 
using the current ^ c< Lab release, version 4.D21. This is important to give a 
sense of the maturity of the platform. Otherwise, I might have been tempted 
to fix up any weaknesses encountered. 

I followed the the explicit model specification[15] step by step, referring to 
the Repast Java implementation on the rare occasions the specification was am- 
biguous. Stupid Model consists of agents called "Stupid Bugs" moving around 
a Cartesian lattice. No two agents can occupy the same location, so movement 
involves selecting a cell within a 9 x 9 Moore neighbourhood, testing whether 
the cell is occupied and moving into the cell if empty. The search procedure 
is repeated until an empty cell is found. Since different frameworks potentially 
use different random number algorithms, initialised with a different seed, this 
introduces indeterminism into model runtimes. In order to reduce the impact 
of this indeterminism, the density of agents was chosen to be 0.1 (4000 agents 
in a 200 x 200 world) so that the standard deviation of runtimes was less than 
10% of the mean. 

For measuring application performance, I did both GUI runs, and batch 
mode runs. In Ecq_ a h a non-GUI batch run simply involves replacing the "GUI" 
command from the experiment script, with a call to "simulate", and comment- 
ing out any graphical calls (plot, histogram and draw). In Repast, Swarm and 
Mason, a separate "BatchSwarm" needs to be provided by the programmer, 
but only the GUI versions of each model were published by Railsback et al. For 
batch measurements, I commented out the call to addAction that added the 
display actions. For the Repast implementation, I changed the batch parameter 
of Simlnit: : loadModel to true, and timed the run from the command line. 
With the Mason implementation, I again commented out the display action, 
and recorded the CPU time so as to discount the delays introduced by hav- 
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ing to click the button. In fact for all platforms, the reported values are the 
CPU time. For the Objective C Swarm version, I modified the code so that 
the StupidModelSwarm was directly called from mainO rather than indirectly 
through StupidModelObserverSwarm. 

I chose to measure the versions 10 and 11 of the Stupid Model. However, the 
stopping criteria is specified as when the maximum bug size reaches 100. Since 
bug growth depends on the availability of food, which itself is a function of a 
random number generator call, and also of the grazing history, this stopping 
criterion is indeterministic. For the purposes of inter-framework performance 
comparisons, I changed the stopping criterion to be a fixed number of bug 
updates (500). 

In version 10 of Stupid Model, bugs will randomly select a cell within their 
neighbourhood, and moving to it if the cell is empty, otherwise repeating the 
selection process. In version 11, all cells in the neighbourhood are iterated over, 
and the bug moves to the empty cell with the most food. 

From version 12, bugs can reproduce and die according to random dynamics, 
so the amount of work per update step will depend on the number of living bugs. 
Even though these higher version models are more computationally intensive, 
run times cannot be compared between different platforms due to differences 
in the order that random numbers are generated. Hence the Stupid 16 mea- 
surements reported in table [2] should be taken with a certain amount of salt. 
Nevertheless, I verified that all models executed for 1000 steps, and that the 
number of Stupid Bugs was roughly the same for each platform (approximately 
8-900 after the initial population explosion). 

Railsback et al. did not do any performance analysis or tuning. For CH — h 
code, performance tuning can deliver big performance improvements. ^ c tab can 
be built with performance counters enabled for the individual TCL commands, 
and a single run indicated that the initial approach used for evaluating the 
stopping criterion (evaluating the maximum of the vector of bug sizes in TCL) 
was very expensive. By implementing a specialised max_bugsize () (all of 4 lines 
of CH — h code) improved performance by about a factor of four. However, for the 
inter-platform performance comparison, the stopping condition was changed to 
a fixed number of bug update steps, so this optimisation makes no difference to 
the performance benchmarks. 

A more detailed performance profile using the standard GNU/Linux profiling 
tool gprof , indicated that updating the food availability was a bottleneck, and 
that cache utilisation could be improved by laying the data contiguously in 
memory, which is not the case when the data is stored as members of a cell 
object. This optimisation, which needed some substantial recoding of the model, 
improved overall performance by a factor of two for model version 16, although 
it only made about a 10% improvement for version 11. It should be noted that 
this optimisation technique should also be available for the Java and Objective-C 
platforms, and presumably may deliver a similar performance boost. 

All performance benchmarks were run on a 2GHz Intel Pentium M processor 
with 1GB memory running Slackware Linux 10.0. The Java version used for 
Repast and Mason was SDK 1.4.2 standard edition. The compiler used for 
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Swarm and Ecq_ a b was GCC 3.4.3. I also did a comparison run using 

the Intel C++ compiler 9.0, but this was more than 50% slower than the GCC 
compiled code. This somewhat surprising result indicates that ice's strength 
lies in vectorising loops that access data contiguously to exploit the inbuilt 
SSE instructions, but that for more general purpose ABM code, GCC performs 
better (at least on Linux!). 

The sourcecode for Ecq_ a b Stupid Model is available from the ^ c £a6 website. [3] 

3 Results 

Similar to all the platforms reviewed by Railsback et al., ^ C( 2afa proved capable 
of implementing all functionality for all versions of Stupid Model. Implementing 
the first version took longer than any of the remaining versions, as £°£afo does 
not provide a ready-to-use spatial library. Instead it provides a more general 
library called Gravhcode^TE\. Graphcode's abstraction is a network, or graph of 
objects, with the links between objects representing data flow. Graphcode can 
distribute the objects across multiple processors using the Classdesc serialisation 
library. A cellular space such as found in Swarm or Repast will be a set of 
objects, each one wired to its neighbours. In such a way, Graphcode can easily 
represent Cartesian and hexagonal topologies by the way the neighbourhoods are 
wired. However, the only example using Graphcode provided in the ^ c £a/j was 
a continuous space example, each cell holding objects located within a certain 
region of space. Examples of models using different sorts of spatial topologies, 
as well as a few common cases being supplied as a library would improve the 
beginner's experience of Ec^at,. 

In retrospect, it may have been simpler to implement the spatial class on 
top of a standard vector of cells. This would have gotten the initial model up 
and running quicker, but limited the model to sequential usage only. By using 
Graphcode, we enable parallel processing capability. 

One thing that became clear in this exercise is the need for a smart refer- 
ence type. Objects like bugs need a reference to the cell in which they inhabit, 
scheduling lists need references to the bugs that they schedule and so on. Be- 
cause bugs move from cell to cell, it is better for the cells to have a reference to 
the bug it contains (if any) rather than for the cell to store the bug itself. In 
C, the only possibility for references are pointers, which are difficult to serialise 
properly due to the fact that C makes no guarantees about whether a pointer 
is valid or not. Substantial care is required to ensure that references remain 
valid in the event of an object such as a bug being deleted from the system. 
Classdesc accepts a pragma that asserts that a pointer is either valid or NULL, 
and whether the pointer chains form cycles or not to allow serialisation, but it's 
up to the programmer to ensure software bugs do not invalidate this assertion. 

C++ also supports static references (eg int&), which are established at 
the time of the reference's creation, and then immutable until the reference 
is destroyed. These references are always valid, however the lack of dynamic 
control makes them unsuitable for agent based simulations where agents may 
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be dropped or moved, and appropriate references updated. Furthermore static 
reference cycles cannot be handled with serialisation at all, since the serialisation 
descriptors cannot distinguish an object from its reference. 

Whilst it is possible to use ^- c tab with a nonserialisable model, one gives up 
substantial functionality doing so, including the ability to checkpoint/restart 
the model. 

What is needed actually is something like Java's reference type, where ob- 
jects are created on the heap, and the programmer simply manipulates refer- 
ences. Once all references to an object have been destroyed, Java's garbage 
collector takes care of destroying the object, reclaiming the memory used. 

It is possible to implement something like this in CH — h, using operator over- 
loading to give the resulting type the "look and feel" of a pointer. Such types are 
usually called smart pointers. The well known Boost library|2| provides a few 
different versions, some of which are being considered for inclusion in the CH — h 
standard library. ^ c tab provides the template ref <T>, which is parameterised 
by the target type of the reference. Unlike the Boost versions (in which you pass 
the smart pointer a pointer for it to control), ref has control over the entire 
lifecycle of the object it points to. The first time a ref object is dereferenced, 
the target object is created on the heap, and it keeps track of the number of 
references to the target object, so that once all references to are destroyed, so 
is the target object. 

The version of ref supplied in the current ^ c tab has a number of deficiencies, 
however, most notable of which is that it doesn't provide any way of testing 
whether the target object exists or not. For the purposes of this exercise, I copied 
the ref . h header file, and added the necessary functionality. This improved 
ref . h will be incorporated in future releases of ^ c< tab. 

Agents usually need to refer to the environment, or world in which they live. 
In languages like Java or Objective C, this is simply managed by having the 
agent store a reference to the world, and/or cell. However, this will set up a 
reference cycle which will play havoc with model serialisation if the serialisation 
algorithm doesn't explicitly account for cycles. E c< Lab provides a routine that 
serialises arbitrary graphs constructed with pointer references. However, it does 
not currently support the presence of cycles with the ref <> data type. With 
CH — h, however, there is a simple workaround. The model is a global variable, 
and agents can refer to their cell by holding an index into a container of cells 
stored within this global model. This is the approach I have taken with Stupid 
Model, and indeed this technique is used in other ^ c tab models. However, if 
the ref <> data type were extended to support serialisation of cyclic graphs, the 
method deployed in Java and Objective C models can be supported as well. 

Line counts are often considered a proxy for the amount of effort a program- 
mer must expend to implement a problem. Table [T] shows the line counts for 
the 16 different Stupid Model cases for each of the Railsback implementations, 
as well as the ^ c tab implementation. The E c< Lab implementation also includes 
two additional cases, which build upon version 16. The model is parallelised 
using Stab's MPI-based parallel processing features, and finally, the "field" 
optimisation whereby the food data is stored in contiguous memory. ^ c< Lab and 
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Version 


Repast 


Mason 


Obj-C Swarm 




1 


158 


169 


578 


253 


2 


158 


214 


622 


259 


3 


250 


263 


865 


281 


4 


256 




896 


310 


5 


312 


296 


968 


322 


6 


306 


362 


1005 


338 


7 


359 


316 


1070 


337 


8 


258 


365 


1144 


320 


9 


368 


369 


1152 


336 


10 


381 


383 


1191 


352 


11 


391 


409 


1253 


358 


12 


497 


494 


1614 


416 


13 


484 




1636 


419 


14 


501 




1360 


432 


15 


646 


670 


1761 


515 


16 


753 


816 


2174 


662 


parallel 








753 


field 








894 



Table 1: Source code line-counts (as reported by the unix command 'wc') for the 
different Stupid Model versions. Makefiles are not included (Swarm & ^ c ^afa), 
since these are fairly boiler plate code, and fairly negligible. E- C tab counts 
include the TCL scripts. 

the two Java platforms seems to need a similar number of lines of code, yet the 
Swarm implementation needed up to three times the number. Whilst a factor of 
two or three in source line count is not particularly significant, it does indicate 
that it takes a bit more effort to implement Swarm models. 

In table [2l execution times for various stupid model versions is reported. 
As described in JjH versions 10 & 11 were run in batch mode with as much 
graphical output turned off as possible. The Java versions performed slightly 
better for version 10, and the C++ version did better on version 11. However, 
given the possible range of implementation strategies, one should not read too 
much into this, except that the myth of Java being slow relative to CH — h should 
be now be firmly laid to rest. The result is broadly in line with other obser- 
vations that Java implementations tend to be within a factor of 2 of natively 
compiled applications [TJ [7]. The results for Swarm though confirm Railsback et 
al's the observation that Objective C performance lags that of the Java (and also 
now C++) versions. Unfortunately, my knowledge of Objective-C and Swarm 
internals is not up to the task of explaining this result. 

In version 16, the full graphical version of the model was run. This included 
a display of the space, a plot of the number of bugs and a histogram of bug 
sizes. It should be noted that the Mason implementation lacked the plot and 
histogram, apparently because this functionality is absent within the Mason 
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Version 


Repast 


Mason 


Obj-C Swarm 




10 


3.5 


3.4 


71 


3.9 


11 


32.7 


21.3 


165 


14.9 


16 


44 


40.5 


402 


1014 


field 








67 



Table 2: Execution CPU times (in seconds) for several Stupid Model versions 
for different platforms. Versions 10 and 11 were performed in batch mode (no 
graphical output, no GUI control, Mason excepted), version 16 in GUI mode 
with a plot and histogram. ^ c ^afa's field version uses raster rather than canvas 
for display, and omits the expensive histogram widget. All these figures need 
considerable qualification (see text). 

toolkit [14 itself, but provided by 3rd party add-ons. One thing that stands out 
is the slowness of E- C tab. The TCL-based plotting widgets used in E C( tab (also 
used in Swarm) are slow relative to the equivalent Java offerings. Furthermore, 
this benchmark displays the space environment using a canvas, which is a high 
level drawing tool with roughly the same sort of functionality as a standard 
drawing application (eg. the drawing application in OpenOffice or Xfig). The 
bugs, predators and empty cells are rendered as coloured squares. The other 
platforms provide dedicated raster objects for rendering spatial displays. In 
the "field" version of Stupid Model, instead of representing the model's objects 
as squares, a single pixmap object is created on the canvas and manipulated 
through low level Tk library calls. This amounts to about 40 lines of code, and 
improves the display performance dramatically. The result listed under the row 
"field" also omits the expensive histogram functionality (but still displayed the 
plot of bug numbers). 

4 Parallel implementation 

Having put the extra work into building the space class on top of Graphcode 
rather than using a simple vector, it raises the question of whether Stupid Model 
can be effectively parallelised. 

The first thing that becomes apparent is that Stupid Model as specified is 
inherently sequential. Two bugs are not allowed to occupy the same spatial 
location, and movement into a location is performed on a first come first served 
basis. Since the order in which bugs perform their update move is randomised, 
the obvious parallel generalisation in a shared memory context is to use locks to 
prevent two bugs on different processors simultaneously moving to the same lo- 
cation. However, ^ c< Lab is designed for use with distributed parallel systems, and 
obtaining the state of a cell located on a remote processor is expensive. In fact, 
in the MPI transport layer used by ^ c tab 1 such functionality is only supported 
by "one-sided" communications of MPI 2, a relatively new feature that is not 
well supported and typically poorly implemented. Instead, the recommended 
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approach in E c< tab is to have separate communication and computation phases, 
with a snapshot of neighbouring data at the previous timestep supplied to each 
processor during the communication phase. 

As Stupid Model is a pedagogical model, there is no one right answer as to 
respecifying the model for parallelisation. Perhaps the most obvious approach 
would be to allow multiple bugs to share a single location within the space. This 
would certainly simplify the code, as additional logic was required to enforce the 
one-bug-per-location requirement. However, in the spirit of adventure, I propose 
the following protocol for allowing bugs to migrate from one processor to the 
next, whilst maintaining the one-bug-per-location property. As in the sequential 
algorithm, bugs examine their neighbourhood, and choose the cell with the 
highest food resource as a destination. If the destination lies on the current 
processor, and the cell is empty, the bug is free to move. If the destination 
is remote, however, the bug's desire to move to a remote cell is lodged with 
an emigration register. Then after all bugs have performed their move, the 
emigration register is passed to the remote processor, which approves or denies 
the request depending on whether the destination is already occupied, or an 
immigration request has already been allowed. The immigration approval list 
is passed back to the requesting processor, and approved bugs are migrated 
between processors. The remaining bugs do not move. 

I coded this solution into the stupid-parallel version, and also the field 
optimised version stupid-field. None of the other versions are parallel aware 
code — building them and running them in parallel will only result in the model 
running on processor 0, with the remaining processors idle. 

With the stupid-parallel version, it became immediately clear that the 
Prepare_Neighbours () step dominated the calculation. This highlighted a 
hitherto unsuspected source of inefficiency in Graphcode's Prepare_Neighbours () 
method. To build the list of neighbours to transmit, Graphcode loops over the 
neighbours of local cells, adding to the list any remote neighbour found. How- 
ever, this leads to many duplicates, as one cell may be the neighbour of many 
other cells — for the Stupid Model case, each cell in the transfer list will be 
duplicated 36 times. In a more common von Neumann neighbourhood of ra- 
dius 1 there is no duplication, and in the Moore neighbourhood of radius 1 the 
duplication is only 3 times. In choosing a Moore neighbourhood of radius 4 for 
their Stupid Model, Railsback et al. unwittingly made this inefficiency blatant. 

However, even with this inefficiency corrected, Prepare_Neighbours() is 
still an expensive overhead. The example problem I tested was the same 200 x 
200 spatial grid, and so 2 x 200 x 4 x N p cells need to be transferred each time 
step (N p > 1 being the number of processors). This overhead can be amortised 
by increasing the problem size. 

In the stupid-field case, the f ood_available data is not stored in the cell, 
but in the additional field data structure, so is not transferred with the cell data 
during the Prepare_Neighbours () step. In fact, only the food data has any 
affect on bug movement, so Prepare_Neighbours () is eliminated altogether. In 
the stupid-field version of the model, we do not transfer the food data, but 
duplicate the update calculation on the overlap area between two processors. A 
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Figure 1: Speedup curves for stupid-parallel and stupid-field for a 
200 x 200 grid with 4000 stupid bugs moving and growing. Bug reproduc- 
tion and mortality as well as predation have been turned off. At no stage does 
stupid-parallel run as fast in parallel as it does sequentially, due to the over- 
heads of the PrepareJJeighbours () step. 

single Prepare_Neighbours () step is done at the beginning of the model run 
to ensure access to the food data. 

Figure[T]shows the speedup curve for both the stupid-parallel and stupid-field 
model, for the same input script used for the stupidlO and stupidll bench- 
marks reported in tabled 

The parallel computing experiements were performed on Linux cluster (Be- 
owulf style) with dual 3GHz Pentium 4 Xeon nodes connected via Gigabit Eth- 
ernet. Each node has 2 GB of memory. 

5 Conclusion 

The aim of this study was to answer the following questions: 

• is E- C tab suitable for the sorts of agent based models that other more well 
known platforms are used for 

• what performance advantages, if any, does the use of C++ provide 

• what deficiencies are present in ^ c< tab 
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Stupid Model is a nontrivial, yet fairly simple agent based model that could 
be implemented without an excessive amount of programming. ^ c< tab has shown 
itself to be capable of implementing Stupid Model with about the same sort of 
effort reported by developers of Repast and Mason versions of the model, and 
was implemented in around the same number of lines of code. Furthermore, 
performance was on a par with these Java-based platforms. 

The main deficiencies encountered were: 

• A lack of specialised space library, or library of examples in the use of 
Graphcode for implementing spaces. 

• A lack of a simple raster object for displaying spaces. The provided canvas 
functionality is very slow 

• GUI functionality is slow compared with the Java-based functionality 

• the smart pointer template ref needs to be improved 

For addressing the space library issue, I will start with implementing a few 
well known ABM models to build up a library of practice. Where code appears 
in common, this can be refactored into a library. 

To address the GUI performance, a possible future strategy is to develop 
a Classdesc C++/Java interface to enable C++ coded ^ c tab models to run 
under a Java framework such as Repast. A similar strategy was investigated 
integrating C++ and Objective C using Classdesc to look at Swarm integration, 
however it never found practical use and is no longer being maintained]!]. The 
feasibility of doing this with a Java platform will be the subject of future work. 



References 



RF Boisvert, J. Moreira, M. Philippsen, and R. Pozo. Java and numerical 
computing. Computing in Science & Engineering [see also IEEE Compu- 
tational Science and Engineering], 3(2):18~24, 2001. 



[2] Boost C++ Libraries, http://www.boost.org/ 
[3] Ec<n a b website, http://ecolab.sourceforge.net 

[4] 



[5] 



James Gosling, Bill Joy, and Guy L. Steele, Jr. The Java Language Speci- 
fication. Addison- Wesley, 3rd edition, 2005. 

V. Grimm and S. F. Railsback. Individual-based Modeling and Ecology. 
Princeton UP, 2005. 



[6] Java Grande, http://www.javagrande.org/ 

[7] J.P.Lewis and Ulrich Neumann. Performance of Java versus C++. 



http://www. idiom. com~zilla/Computer/javaCbenchmark. html 2003. 



11 



[8] Richard Leow and Russell K. Standish. Running C++ models un- 
der the Swarm environment. In Proceedings SwarmFest 2003, 2003. 
|arXiv:cs.MA/04010"25| 

[9] Sean Luke, Claudio Cioffi-Revilla, Liviu Panait, Keith Sullivan, and Gabriel 
Balan. MASON: A multiagent simulation environment. Simulation, 81:517- 
527, 2005. 

[10] Duraid Madina and Russell K. Standish. A system for reflection in C++. 
In Proceedings of AUUG2001: Always on and Everywhere. Australian Unix 
Users Group, 2001. 

[11] David McFadzean. SimBioSys: A class framework for biological simula- 
tions. Master's thesis, Dept. of Computer Science, Calgary, Alberta, 1994. 
|http : / / www . lucifer .com/~david/ thesis/) 

[12] Nelson Minar, Roger Burkhart, Christopher G. Langton, and Manor Aske- 
nazi. The Swarm simulation system: A toolkit for building multi-agent 
simulations. Technical Report WP96-06-042, Santa Fe Institute, 1996. 
http: / /www. swarm.org 

[13] M.J. North, N.T. Collier, and J.R. Vos. Experiences creating three imple- 
mentations of the Repast agent modeling toolkit. ACM Transactions on 
Modeling and Computer Simulation, 16:1-25, 2006. 

[14] S. F. Railsback, S. L. Lytinen, and S. K. Jackson. Agent-based simulation 
platforms: Review and development recommendations. Simulation, 82:609- 
623, 2006. 

[15] Steve Railsback, Steve Lytinen, and Volker Grimm. StupidModel and ex- 
tensions: A template and teaching tool for agent-based modeling platforms. 
http://condor.depaul.edu/~slytinen/abm/StupidModel. 

[16] Marc Snir et al. MPI: the complete reference. MIT Press, Cambridge, MA, 
1996. 

[17] Russell K. Standish and Richard Leow. EcoLab: Agent based mod- 
eling for C++ programmers. In Proceedings SwarmFest 2003, 2003. 
arXiv:cs.MA/0401026| 

[18] Russell K. Standish and Duraid Madina. Classdesc and graphcode: sup- 
port for scientific programming in C++. International Journal for High 
Performance Computing and Applications, 2006. submitted. 

[19] Bjarne Stroustrup. The C++ Programming Language. Addison- Wesley, 
Reading, Mass., 3rd edition, 1997. 



12 



